Would be nice if this would be somehow configurable

What would be a good way to handle it? Another global variable? An extra parameter?

What if we update each multiplicand with multiplicand.value = multiplicand.value % backend.get_modulus()? Then, the maximum exponent would be limited only by bitlength. That would make the output LinComb's value and __repr__ wrong, but would increase performance and shouldn't affect the actual circuit.

It might also be worth thinking about how to handle LinComb.value when it overflows. Should we leave the value as is or wrap around? If we were to wrap the value around (e.g. in __init__), it might easily solve these issues.

Yes, doing multiplicand.value = multiplicand.value % backend.get_modulus() definitely makes sense. Of course other.to_bits still requires a bit length, but I guess we can just use the default bit length and if the user wants to have a lower bit length (because of efficiency) he can just temporarily change it.

And indeed, it is a good point about the overflows. Originally the code used to just always reduce modulo backend.get_modulus(). But later my idea was to keep stuff completely independent from the modulus wherever possible. Because who knows, one day there may be backend that just works over the integers and doesn't use a modulus at all. In fact, the only place where get_modulus is now used is in the hash code.

Maybe instead of using backend.get_modulus(), the backends should instead support a backend.reduce(val) function that performs modular reduction...

Should I just reduce using backend.get_modulus() for now?

Yes, let's just keep it like that at least for pow. It doesn't make much sense to do a pow that has an overflow, so in practice it shouldn't matter.

I made the change, but oblivious pow now costs 7 * bitlength + 1 constraints. Is that acceptable?

This should work. It will const bit_length constraints due to the right-shift (at least I assume (1<<resolution) is implemented with a right shift in runtime.py? otherwise it is more costly). The previous code did two assert_positive's of size equal to the resolution. So it seems that depending the resolution and the bit length either of the two could be more efficient.. There would also be differences in the sizes of the inputs that they would accept.. I would have to think a bit more about which version would be preferable in which cases.

Good point. LinComb.__rshift__ uses a division right now instead of to_bits. I'll have to change that and change the fixed point code to use >> (1 << resolution).

Could you explain the constraints you had before? Are they still required here?

diff = (1<<LinCombFxp.res)*ret.lc-self.lc*other.lc
(diff + (1<<LinCombFxp.res)).assert_positive(LinCombFxp.res+1)
((1<<LinCombFxp.res) - diff).assert_positive(LinCombFxp.res+1)

Actually, I did some digging and it turns out that LinCombFxp.__mul__ costs only 1 constraint, even with the division. I traced it to LinComb.__truediv__ costing 0 constraints to divide by a public integer, and (1 << resolution) being a public integer.

Could you check that LinComb.__truediv__ is correct?

LinComb.truediv as it is now implements proper division, meaning it only works if the division does not have a remainder. So you can divide 8 by 4 (and so do a right-shift by two), but not 9 because this division has remainder one. So you cannot use truediv to implement a right-shift, it should be floordiv. I think for a right-shift there is really no other way than doing a bit decomposition one way or the other

I see.
I'll implement it using floordiv for now. Using a direct rshift with bit decomposition is cheaper, but we easily run into trouble because of to_bits since the numbers are often larger than 2 ** bitlength.